1. Field of the Invention
The present invention relates to a system and a method for Session Initiation Protocol (SIP)-specific notification (i.e. SIP-based notification) corresponding to an event subscription. Particularly, the present invention relates to the improvement of a method for notification corresponding to an event subscription. Also, the present invention relates to the improvement of a system and a method for notifying a presence event in order to forward presence information in a presence system, by using the system and the method as described above.
2. Description of the Related Art
“SIP-Specific Event Notification” identified by RFC (Request for Comments) 3265 of IETF (Internet Engineering Task Force) describes a method for forwarding a state of a particular event by using an SIP SUBSCRIBE and an SIP NOTIFY.
FIG. 1 is a flow diagram illustrating an SIP-specific event notification (i.e. SIP-based event notification) method. Referring to FIG. 1, when a user desires to keep up with the latest information on the state of a particular event (i.e. the latest state information on a particular event), he/she subscribes to the relevant event as a subscriber. A subscription target having state information on the relevant event continues to notify the subscriber of the latest state information on the relevant event in response to a request of the subscriber.
FIG. 2 is a flow diagram illustrating a typical example of a signaling flow in the SIP-specific event notification method according to the RFC3265. As described above, the subscriber forwards a SUBSCRIBE request to the subscription target with respect to a event named “foo”. The subscription target determines if the subscriber can subscribe to the “foo” event. When the subscriber requesting subscription to the “foo” event is authorized, a current state of the “foo” event that the subscription target knows of is forwarded to the subscriber by using a NOTIFY Subsequently, whenever a state of the “foo” event is updated, the most recently updated state of the “foo” event is forwarded to the subscriber by using a NOTIFY.
A presence service requests and forwards presence information by using the SIP-specific event notification technology as described above. To this end, “a Presence Event Package for the SIP” identified by RFC3856 defines a presence event package. Herein, the presence event becomes the presence information. Referring to FIG. 3, a watcher can request presence information of a presentity through a subscription to the presence event. The presence information of the presentity is forwarded to a presence server of the presentity (i.e. a presentity's presence server) which maintains the presence information of the presentity. Through a series of notifications of presence events, the presence server forwards the presence information of the presentity and updated presence information thereof to the watcher.
FIG. 4 is a flow diagram showing a typical example of a signaling flow of requesting and forwarding presence information by using a presence event package. In FIG. 4, the watcher, the presence server of the presentity, and the event correspond to the subscriber, the subscription target, and “foo” as illustrated in FIG. 2, respectively. Accordingly, as in the process illustrated in FIG. 2, the watcher makes a request for a subscription to the presence event to the presence server of the relevant presentity in order to receive the presence information of the presentity. The presence server of the relevant presentity authorizes the subscription request, and then continues to notify the watcher of the most recently updated presence information on the relevant presentity.
By expanding the scheme for providing a presence service on one presentity as described above, the watcher can simultaneously subscribe to presence services on multiple presentities. To this end, the watcher subscribes to a presence service on a presence list by using a Resource List Server (RLS). The term “presence list” refers to a set of multiple presentities. By subscribing to the presence service on the presence list, the watcher can simultaneously subscribe to presence information on the multiple presentities.
FIG. 5 is a flow diagram illustrating the process of subscribing to the presence service on the presence list. In FIG. 5, if the watcher requests a subscription to the presence list, the subscription request is forwarded to the RLS. The RLS resolves the relevant presence list, and subscribes to a presence service on each of the members on the presence list for the watcher. Thereafter, the RLS receives the presence of each presentity, aggregates the received presences, and simultaneously forwards the aggregated presences to the watcher. By doing this, without the need for a subscription to a presence service on each of the multiple presentities, the watcher can simultaneously obtain the presence information on the multiple presentities.
In the SIP-specific event notification technology as described above, whenever an event is updated, relevant notification is generated in order to forward the updated event. Accordingly, the requirements of a system need to become more sophisticated in order to forward and process each generated notification.
Especially, in the case of a presence service provided by using the presence event package, when considering multiplicity of the watchers and presentities and the fact that the presence information is frequently updated, a traffic load becomes unbearably high due to the notification of a presence event generated whenever the presence information on each presentity is updated.
As a result, there has been an urgent need for a scheme capable of effectively reducing the SIP-specific event notification, especially, a volume of the presence event notifications.